 1.调整 Map 数
   
   通常情况下，作业会通过输入数据的目录产生一个或者多个map任务。主要因素包括：
   输入文件总数
   输入文件大小
   HDFS文件块大小
   map越多越好吗。当然不是，合适的才是最好的。
   如果一个任务有很多小文件（<< 128M）， 每个小文件也会被当做一个数据块，用一
个 Map Task 来完成。
   一个 Map Task 启动和初始化时间 >> 处理时间，会造成资源浪费，而且系统中同时
可用的map数是有限的。
   对于小文件采用的策略是合并。
   每个map处理接近128M的文件块，会有其他问题吗。也不一定。
   有一个125M的文件，一般情况下会用一个Map Task完成。假设这个文件字段很少，
但记录数却非常多。如果Map处理的逻辑比较复杂，用一个map任务去做，性能也不好。
   对于复杂文件采用的策略是增加 Map 数。
   computeSliteSize(max(minSize, min(maxSize, blocksize))) = blocksize
   minSize : mapred.min.split.size （默认值1）
   maxSize : mapred.max.split.size （默认值256M）
   调整maxSize最大值。让maxSize最大值低于blocksize就可以增加map的个数。
   建议用set的方式，针对SQL语句进行调整。
 
 2.调整 Reduce 数
   
   reducer数量的确定方法比mapper简单得多。使用参数 mapred.reduce.tasks 可以
直接设定reducer数量。如果未设置该参数，Hive会进行自行推测，逻辑如下： 
   1).参数 hive.exec.reducers.bytes.per.reducer 用来设定每个reducer能够处理的
最大数据量，默认值256M
   2).参数 hive.exec.reducers.max 用来设定每个job的最大reducer数量，默认值
999 (1.2版本之前) 或1009 (1.2版本之后)
   3).得出reducer数： reducer_num = MIN(total_input_size /
reducers.bytes.per.reducer, reducers.max)
   即： min(输入总数据量 / 256M, 1009)
   reducer数量与输出文件的数量相关。如果reducer数太多，会产生大量小文件，对
HDFS造成压力。如果reducer数太少，每个reducer要处理很多数据，容易拖慢运行
时间或者造成OOM。
